Hardware debugging devices are often employed in the debugging of electronic systems involving digital processors. Such hardware debugging devices are usable to identify hardware defects in a new system, to debug and develop software for a new system, and to load software onto systems both in testing environments and in production environments.
FIG. 1 (Prior Art) is a simplified diagram of one type of conventional hardware debug device 1. Hardware debug device 1 is coupled via an ethernet network connection 2 to a host computer 3. Host computer 3 may, for example, be a workstation that runs an operating system 4. Hardware debug device 1 is also coupled, for example via a ribbon cable or other type of connection 5, to a target processor 6. Target processor 6 is embedded in and is a part of the system to be debugged.
An engineer or software developer sitting at host computer 3 can generate software code to be executed on target processor 6 of the new system. When the code is ready to be loaded into program memory on the system, the host computer 3 sends an appropriate memory load command to hardware debug device 1. This memory load command may, for example, include a starting address field, a length field, and a data field. The memory load command is, for example, sent in the form of the data payload of a TCP/IP network packet across the network connection 2 to hardware debug device 1. To do this, the engineer or software engineer may use a software debugger program 7 that is an application program executing on the host computer. The protocol processing stack 8 of host computer 3 handles the protocol processing necessary to transfer the load memory command over network connection 2 to hardware debug device 1.
Hardware debug device 1 receives the command, identifies it as a memory load command, and then executes a corresponding software routine 9 that causes a load memory action to be performed. In the example of FIG. 1, hardware debug device 1 has a real time operating system 10 as well as a stack 11 for handling the protocol processing associated with receiving the command and passing it up to debug routine 9. Debug routine 9 is an application program, or part of an application program, executing on hardware debug device 1.
Debug routine 9 carries out the load memory action by causing on-chip debugging hardware 12 on target processor 6 to perform certain sub-actions. In the case of a load memory command, sub-actions may include writing individual words into individual program memory locations. Many such sub-actions may be required to carry out one load memory action.
On-chip debugging hardware 12 recognizes certain debug commands that are received onto the on-chip debugging hardware 12 in serial fashion through a serial interface of the on-chip debugger. One of the commands is a command to write to a program memory location. Debug routine 9 therefore causes hardware debug device 1 to send the appropriate write-to-program-memory commands to the on-chip debugging hardware 12 such that the on-chip debugging hardware causes a block of code to be written into the appropriate block of program memory, one address location at a time. The commands understood by on-chip debugging hardware 12 of the target that cause the sub-actions to be carried out are referred to here as “microcommands.” The commands sent from host computer 3 to hardware debug device 1 that instruct the hardware debug device to perform the higher level action are referred to here as “macrocommands.”
Typical on-chip debugging hardware supports numerous microcommands other than the write-to-program-memory microcommand. Such microcommands may include, for example, microcommands to stop the target processor, single-step the target processor, read and write to various internal registers within the target processor, read and write to data memory, set breakpoints in code executed by the target processor, stuff instructions into the target processor, read and write watchpoints, read status registers, and otherwise exercise and monitor the target processor. These microcommands are usable to carry out sub-actions involved in executing other macrocommands.
Although the hardware debug device 1 of FIG. 1 has an operating system, other conventional hardware debug devices have debug routines or code that execute without an operating system. One such hardware debug device 13 is illustrated in FIG. 2 (prior art). The overall function of the debug routine 14 in the example of FIG. 2 is similar to the function of the debug routine 9 in the example of FIG. 1 in that it receives macrocommands from the host computer and issues microcommands to the target that cause a desired action to be performed. The hardware debug device 13 of FIG. 2 can, however, be more robust and reliable in that instability problems associated with the operating system 10 are avoided. Moreover, hardware debug device 13 can often be made to be less expensive because the hardware debug device 13 of FIG. 2 need not entail the memory necessary to store the often large operating system program.
One example of hardware debug device 13 of FIG. 2 is the “ZPAK” development tool available from Zilog, Inc. of San Jose, Calif. For additional information on the ZPAK device, see the “ZPAK Datasheet” ZDI23200ZPK, which can be found on the Zilog.com web site. One example of the on-chip debugging hardware 12 of FIG. 2 is the on-chip debugger (OCD) available in the Z8 family of 8-bit microcontrollers available from Zilog, Inc. For additional information on such an on-chip debugger, see the “Z8Encore Microcontrollers with Flash Memory and 10-bit A/D Converter” Preliminary Product Specification, and more specifically the chapter entitled “On-Chip Debugger”. This Preliminary Product Specification is available on the Zilog.com web site.
FIG. 3 sets forth an example of source code for a firmware routine that handles a load memory macrocommand. The source code is compiled into a block of object code that is then executed by an eZ80 processor of hardware debug device 13 of FIG. 2.
Although hardware debug devices such as those set forth above work well in certain environments and for certain purposes, these hardware debug devices have certain problems. For example, different target processors from the same manufacturer or from different manufacturers may have different on-chip debugging hardware. These different on-chip debuggers may have different capabilities, require different microcommands, and use different communication interfaces and protocols. If an engineer or software developer has a given hardware debug device that is designed to work with one type of target processor, and if the engineer or software developer wishes to switch to a different type of target processor, then the debug routines in the hardware debug device may need to be modified or replaced. One hardware debug device may not work with multiple different kinds of target processors. It may, for example, be desirable not to have to modify the hardware debug device when upgrading from one processor in a family of target processors to the next processor in the same processor family, yet the hardware debug device may not function with the new type of target. This inflexibility associated with the hardware debug devices of FIGS. 1 and 2 is undesirable.
FIG. 4 (prior art) is a diagram of a hardware debug device 15 that has increased flexibility. Rather than sending macrocommands to hardware debug device 15, lower level commands are sent from host computer 16 to the hardware debug device. These lower level commands give the hardware debug device 15 increased flexibility because one set of microcommands can be sent that allow the hardware debug device to interface with a first type of target, whereas a second set of microcommands can be sent that allow the hardware debug device to interface with a second type of target. Much of the processing that was performed in the hardware interface device in the examples of FIGS. 1 and 2 is performed on host computer 16.
Although a system such as the system of FIG. 4 may overcome inflexibility problems associated with the hardware debug devices of FIGS. 1 and 2, systems such as the system of FIG. 4 suffer from other problems. There is, for example, increased information flow between the hardware debug device and the host computer. Because the host computer is performing more monitoring functions in the example of FIG. 4, speed of communication across the network connection 2 between the hardware interface device and the host computer becomes increasingly important. In a packet-based protocol such as TCP/IP, a small payload often cannot be sent without involving a considerable amount of protocol processing overhead and a considerable amount of information flow across the network. In the case where the target processor is sending a large number of small pieces of information back to the host computer via the hardware debug device, the corresponding large number of packets can slow the communication between the hardware debug device and the host computer to undesirably low levels.
Moreover, it is generally not desirable to require the host computer to monitor large volumes of communications from the target processor. It is preferable to have the hardware debug device offload the host computer of low level tasks. Having the hardware debug device handle debugging and testing actions on behalf of the host computer frees up processing power of the host computer for other uses. For example, an engineer using a workstation on the network who sets in motion a particular test of a target processor may not want the workstation to slow down during the running of the test because the workstation is receiving a large number of TCP/IP packets back from the hardware debug device.
Accordingly, an improved hardware debug device is sought that is flexible, fast, inexpensive, and reliable.